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INTERPRETER TO UTILIZE INTERPRETER 
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(57) Abstract: 

PROBLEM TO BE SOLVED: To accelerate the execution 
speed of an interpreted computer program and further to 
provide an efficient interpreter concerning resources 
required for the interpreter. 

SOLUTION: Concerning this method, the execution 
speed of a program to be interpreted is accelerated by 
using an operand stack. The most significant values of 
the operand stack are stored in registers 305, 405, 407 
and 409 more than one. The state of the interpreter 
shows the data type of the most significant operand 
stack values stored in the registers more than one. 
Concerning a memory requested for the interpreter, the 
high-speed efficient interpreter can be generated. 
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[MH**©ttH]' 

[!**4l ] fe$k<Dlsz/X#*$ts^l/t*~~* is* 

[1**912] &f—9 9 4-fft* &3£, ftfiBft, * 

f**4 i icfS®^^& 0 
[i**43] tt^— ^^>rm, 1**^9 ^Kx^jy 

6, f**4i-3 0^rfta>iolcEmoafeo 
[1**4 5'] M'ftov^^tt, Sfc3^-**-f 

[S**4 6 ] ^V^/y *0#^C£oT^£;fr*L 

!**4l~5UllE«0*ifc. 
[f**4 7 ] tt>T ^9-f y ) ^ 'tt J a v a{S5g^^V-C 
*>5, 1**4 1 -6 ©V^r^JMCEttOS-ife. 5(7 
[1**4 8 ] VC?**&£tf=^f^ — # 

^9J*y 9 oytmit, BEU»oi/^?o'>4<j:ti 

1/ i;^ hSR*^ ? y ? y9<Z>&± 

4iLcofttbcom.co j f—# 9 4 -?%7t: U 40 

-<>'9 9&Wt<-ftlb<D. *f ^9 yy 9 <Oft#><£>^ is 
t°~ — 9^ — K5:^it^xr^ 7"* fit*., 
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o r -r ^ y £ * W * 1 * ft 3 « & r ^ -t * +■ z> r. i: t c j; 
or, siftShs, f**48 \ci&i&<D*m. 

[1**41 0] «SB, IttEffl^S'V'** 
K-f^^y #oaftco*t«4r*jtt-f 1**4 9 tela 

[!**4l 1] tt*tt\ K^y^/y^O^Oay 

t^W^JftMt^ t»*4 9fc!B«<o#«S. 
[f**4l 2] ttai^S^HIKftrKffrStt-r^^ 

7°y 9 <ofz&<D=>'\?=.—9 =2— k«\ is^v^^y * 

♦tc £ o r -f is? v 9 * tttt £ * ftfc h* 

&v£&~k K«fcoTS8££;ft,5, 1**48— n^f 

[1**41 3 ] ftCfia-eC/ya- K*7ae V^TZ 

Hew v^/y ^oa^^a^f*— * =3 — k 

KUH*"* £1**48-1 2UllB«<D-#8r. 
[1**4 l 4] tt»tR*Hfe{E«^^v*«<o»tTO 

^^-K^^^r^^T 1 ^^, E tcli £5 f**4 8- 

[i**4 1 s] »a«*ixfe(Ea^'>^***5ajRs 

tt^lSo^ — 4r^^-T^, 1**48 — 1 

4©fBm*»^ia«o*2fe. 

[1**41 6] tt^^^y^lija vafi?@^->y 
■C**, 1**48-1 SlcE^^a^o 
[*W©»lBft»W] 
[0 0 0 1 ] 

9^V 9<04>'7 , »* ls*T—i/s ts&Xfi±tit\£W?&o 
«tf9*flett^tt^ ^^j/^^<— (stack-based) fife 

[0 0 0 2] 

-MJ"C*>6 J: ^ICKff Shfe, *7i/=9 hmfa<Ofei& 
-fa ?J % >^-i-fi*rfc^ 0 Java*™ <*fctt:ffil®# 
K) ■CffiiSS^a^fat — ^^e^^Att, Java 
TMffijft^- y^CioT Hfr $ 6 46 oiSffl ^ <^ 

i:ay;^AS^S:i:*S"C*«. -m^, JavaTM 

Tf>'<>'9 7}) 9T&Z. 
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[0 0 0 3 ] J a v aTMM^'^'^/tfe^fiS^^^ 

EA±gW h^^ts^ 
><h=3— Kit, r^^^r-f/H iP¥rffra4#sij<z>7 

^ 9 * 7 r -< > li ^ * >w x — :/ /Us J: & fifi o ft A ©1» 

[0 0 0 4] loJKiO^?^7r-f^*JV^J a v 

— 9?u#JJ*Xt^ J a vaigf^^^y^y^y 

iCibM^T, ^^^^Tl- (unmodified) , HfT^frS ^ 
id*"C#S. J a vafif^i/^lt JavafiS^^ 

\£ b * V ^ r i: & "5J flg t £ b X v ^ 5 £ * B * T <fc 5 , 
r-KW4 (generic) J ^ V — ^ CO V 7 h 9 * T 

[0 0 0 5] 

9k-*-S»Hl J a vafi^'>V 20 
♦ttIC, ^]) yhZfrfr (interpret, fl?3K£ 

^*t£*x3 r t as-c# 6o-t\ — 7*1) ^ b 

AcoHt?<t 0«< 
[0 0 0 6 ] ^fy^-/!J s/ bSfrfc:*** 9 = 

*-7°y*tt, <«*.tf, ;**y) «r«»br % b 
L^ot, -f^-T'y^^/tT'p 

[0 0 0 7 ] t<Ofttb, -f^-^y ^ h ^HTV^3 
VtT*-* :/*:/7AO^T&££ft±£^£^bV^ 
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[0 0 0 8] 

coffico^— * * -r y°& ?F-ttt$>\c%\\R £ ti z> * zco&m 

#J«^TIB-C*>*r i:«r^niB^-r*. r^o^P^^v^<o^- 
[0 0 0 9] &5H;&W£ibM^Tfi, *^9^Kx^y 

^^r^tf-o-^^y ^^r^r^^y ^ yhnwcay 

^j&b/t 1 O^J:(Dl/i/X^^^$nT, r 
y^OiRffltt^ 1 oEJLJiOV^^^lcftWSne^-^^ 

7 B y^ttJav aiSaS^->^"C*) "9> ^^7"y ^ 

[0 0 10] SU<oSK160iJlc*5V^'C ft, io^±^yi?x 

(through) ^^6:^:^6. *»f9igb^*5 
v^X, <S?B^^^**4BJ:V^^^^y #<ott»d s »« 

y ^«:e< i: ptc-f^ry^o/t^^^t 0 ^— ^ ^ 



1 
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^Sft^^f y°y * <o#figi UK.»-^»"**' 
SIl:l:J:ot«#Sh5rti5tt5. S 3S1R 

[ o o i i ] toojgftwtcis^TW:, = >-t>^— ^-c*j 

CD* ^-7 is K** ?/^OSJltt<Ojt^OfficO^— 

[0012] teo3Saff«c*5v^xn, <K3B-^^^A^<o 
-f y°y ^ofctfxorn^f ^ — *T "5TK*fflEflc^J;o 

l^)7>f-;VK5:tt§f^tfc«5r, *y-f— ^ 
y^o^filJi, l o&Jbouc?x^^3ftjWi**T,fc^ix# 

w\ -fv^yy^ottari. sft, mmsi* 

[0013] #WW©ttO««^*IJ,£tt:, SSttBEfcM 
[0014] 

*«" 

kRIScfc. (optionally) l'o^io^^y Ki:i:ot 
5 (software emulated) v/f ^ a/nirjyf ^ytli^ 



(4) WMJSPI 1 - 8 5 5 3 4 

6 

fi^O (Native) "^S^^-ft^ - 4#5£<£>^r*< ^ b yn 
-tt 5/ * It ft =2 ^ » — # O T — 3r f=* £ ^ -V V> ft t C K 

5) o * - #y?\<D3r*zfisx.9 V tints'? 

* * -f 

$ y 2 • 

^Fn-Wv^ (BCP) - Hfr^^tv^ 
Sfi^J a v afE©-*^^-^ hn- 

•7ay9J*#Vl/# (PC) - Hff^ttTl^-r ^ 
*yy*£> (AMftlCfi, H*o) -^v* 

^v*yy - -rv^yy *&*tnit'tz>yy- 

[ooi5] mm 

&T\cm< Hmc&^Xs J a v a 

v^^- (^<-r h=2— k) *nn-r%>it$><D j a v 

^S/>t^y^Myht5 (implement, 
30 -Vt^aytf^-^ (Intel x86-7^^n/ 

/y^Vf^-^3 V (implementation^ 1^^,) tCPfibH 

[0016] mitt, **w©SMa«oy y h ^r^: 

^ ^^y— ^5, *-ytf*j/b7, *-*-K9, -^^^ 
1 1 S:^t^= vtfcr — ^ i/Xy'j* i Sr^UTV^o -^9 

XttUTZ (interact) 1t#><D 1 OJ^tJb^^^ ^i^T 

-raf— *i:*4r«a*atfy y b ^^r^n^^^Sr 
-ROMK9^f^l 3, y'XfA^ y s iSJ:^^— K 
5(7 K4W»WftE«S!Eflci: UCD-ROMl st^m^ti 
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#S) ^tyrg (carrier wave) T Zfrft?*— 

-c#s 0 

Bgf 5 5 /n-KK?^^) , UAw<^ 

(removable, #Bl*rii&Jfe) BBtft^lK 5 7 (Witf, C 
D-ROMK^^^) , ^^^W7m5 9, * 
9^K*— K6 1, 3, *5j;V*y h? — * 

[0018] 3ytra-^i/^rAio*>^f A/<^r 
fe, r^ko^enw:, 

y* n ir s> -9- & > x x > y *S J; [Hf -f x ^ v >f T ^ ^° 

too a^t'*—* T-^f^^Yfc^rsr 

[ 0 0 1 9 J iS^iai, J a v a 7°n #J * V^SW 
fett, *r<D&lC. J a v a^^^iaot^^^ 

So h =2 — k«\ -f — :/y 

0 3 W\ — y*y *T£>£, Java 

<K*^^^^J;5jStTS:au-C, »3»4-ffoj a v a 
y — — K^Jigff (progression) 4r^UXV^So 
[0 0 20] J a vay-^3-Kl0Ui, Java 
*ClSa*H/t*mWfcH e 1 1 0W0 r 1 d/o^7A 

*£A/tM^S. y — — Kli, y— * = — 

-< 9 1 0 3 t£A^£-ft,£o Y 3— Ktt, yyh?^ 
T^X^^l/— f*f"?> (software emulated) sVtf^- 
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AMtfnCtt, gf^^^^fi^x^ys/^ (generi 
c) -cfcs mtL<r>^'<< P o 7°n-fe^f-*/t 

OTli/^v^) As ba»U l^ori:^iS*^^^TV^^ 
V\ b =J— K = y It, J a va/P^^A£D 

y ftlb<Os<<{ h — c* tf J a v a jr 7^7r^> 1 0 

[0021] Java ??X7r^tt» J a v a {gj» 
70 ^^^10 7^*^5,, J a vafi^^^lt, J 
a v a ^^^7r^M^l^M h ra— KSr^a — KL 

nfrrs-f ^tfc^o r.^ j a v a {s^^ 

[0022] ^^yy^ii, jeiT^^nir^^a*pi£ 
ii a6£o 

r <k (implementation) ("Tttfefe^ H?T^ ^ ^ 

50 (implement) o iUff* X y°»L ' h = — KaK-f ^ 
^ 365*<D/^ ha— KSrit-t-J: 5 1-, ^^^^v^^r-r 

1ft V b = - K^^f O i: I 4© (at) 

— r^^-/yf-S/ g yt>f^/l/ (implem 

entation cycle) J fc P^tfttS. 

[0 0 2 3 ] #*uv^SSflsWtc*5V^Xtt, -fiyp-^VP 
ott>i:i\ i^ot, rr-cta®^^ 

[0 0 24 ] J a v a ffiffl.-^ ^V^HSdb* J; UC^fife 
. J a v aiSf^v/y^^oM^^V^^Ij:, x ^ y 



<e) 

LiftftlN, 

[0 0 2 5 ] 0 4 (a) tt, ^-^ 2 0 3S:^t^^ 
# yt 2 0 1 Sr^LTV^o r <DX* y^im^ s X, >f 
y*s>*Jbffi (hy7) K t^yis^i T 

5rH>t*^ 0 ttfrvtc 'f—fm* r^^^j lt 
3/*<D*±tea»fc«r (off) rtms. 

"C#, -tix-c, -e^** s^fc: 
y-7r-^brn (FiFo) ^ «js-ea> 

k tt^Dibntv^So *9 (SP) 2 

0 5te, 3/^ 2 0 1 0*_bfl:SrJgLJf'?-. r^/h 

S P»i, 7*— ^fita 5 *^ 2 0 1 JbiCTV 

m (maris ^*yoT®*^«*ts*s) -c^s 

10026] Java ifclg^ isls<DtL)sb ^" i/ Wfr 

4m, H4 (a) tc^Sftft:;** y ^{cmn^rt^r^y 

tt, J a v a<E3B^v'>'IC*5ftS^-^9 ^ K** </ £ 

s<*7^Y7$ yttfl a v afiffi^^^cabM^TflJjfl* 
* a>£r ^ -r rt: 46 iC# t ft *9 » * — 0*J T th 3 o 
[0027] Java y — — \ff>^ h * ^ Y 

X : = A + B&^fri U X, A, B tejS^&St 

1 . I LOAD A 
2. I LOAD B 

3 . I A D D 40 

4. IS TORE X 

uv^^ 0 (long) setter* r L j , 

(single-precision floating point) left: 
I" F J > (double-precision float 

ing point) tCtt TDj IC <fc oT#£ * *T,£fdl<D^ — * 
$ 4 7<Dlt#><Dtt$:s-rZ>s^ b=a— Kd 5 #ffii-*o J a 
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*«*#ib/h*A*9*-##-<^w:3 2 try 

ttftl^»^Tb*)* (#'J*:tf> IBM^-yt/l.ayfa 

ftVO , ^It, J a v % a<R3B-^-»'**i:, i&lg^is 

[0 0 2 8 ] I LOAD^ h=a — Ktt, ^»A 

Ottt^^vK^^ y^ii:n-Kt5. |p]1Sld, 2 
LOAD^W h=a— Kfij\ S^BOfilS:^^^ 

y^±icr"-x^»-r«. ^«*H6J:5^ 1ST 

[0 0 2 9 ] *^^ovK ofcwoSMIiMra:, 5*— ^ffl[d5 

§I*^V^T (^-^9^ K^^ y^<0*±tt*MFiEUftV^ 
^ffi (intervening) /Mb=-Ki:»^ izftttftft 

•9i^*ft-f v^-^y x-^a isicmm-tz. 

[0 0 3 o) 1214 (b ) tt, ^ 3 0 3 Sr*j(A-t-4* 
^^K^^^301 ^/TttV^o ^ 3 0 3 

*-«r^tfo 5/^^^T>^' (S P* ) 3 0 7tt\ * 

(Witt. »ftS^ K*5J;W> y 
[0031] e^^ft s^e^— ^ c/^fAttt^ 



t 
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fifftZo ra^h 6 ^ — *tt3 2 try 

:fe£U<6 4 tT y Ffl©i/^!?Srtt5 ^t* 5 
"C££o {E«Wft= ^^-^±018^3 2tT y UK 

^(O^—f fficDirw X& W^i-T u is* # tcZtD'?—* Sr 

[0 0 3 2] «fc *>*{M«>fcH\ I BM/^yt^a^tf 
~ — 9 (Intel x 8 6 T~$c*7~2 ^< 
Wjto/t^'f Ui?X#&<£U 0 3 2tTyhU>?;* 

* (W*.rf, eax) , iaj:t^»»/h*j«*>^^* 

F (0) ) ^D^.T, Intel x 

8 St^P a ^fn± yy-o>*f— $ # 4 -?<D^< oa&»«\ 
J a v affi^S^CfettattJStti: tt*4ofct^X 

Mitf, I n t 

el 8 0 3 8 6-7^ ^ O^Dt 5/t^*5V>t, 1 6 f 
!/h«T*>«K SfcttM*^-**^:^*, 3 2 tfy 20 

•>^0#JES*02|£»0*>rX-C*)5. Jav 

afif^^y^x 8 6 ^^^iic-o-^y ^yb^nt 

V>-5if*bV^^JiC*5V^T«, Jav t1Bte-*isls\C 
[0 0 3 3 ] BLffncifi-sfcJ: ^^{S^^vcd 

IKMUcWBU^Ife**^****. J a vafi»^i/y 

hra— KJ&*H«i-* (pertain) ^ — $ $ 4 ^ifi^t <Z>4fr 
mCftft-rZ <M*.tf, I STO REtC*5l>T\ Tlj 

t") x 8 6 -^^r ^ a y f-co/ttf><DTir :x;/y =a — 

a. 

[0034] Ei4 (b) \c^mcmz> tt^tt 1 

(c) fi, x 8 6 nr-r £ o /at y-rjiic-r y/y > v 
VSKfc J a v a1gi1&'<?i/l/<Olt1b<a*<<7 VKX? y 50 
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MOl^/TLtl^. t^7>K^^J/^4 0llt 
t"^^4 0 5, 4 0 7, ^^li4 0 9^1OlCW^ 

(*]cd^— Offia-Sr^tf?*— * 4 0 3 Srttllrti-*. 

£/ttf>03 2 tTy b (EAX) "C&6« VS?X 

^^^«P*t*Sr«*t5ft»<0 2oO3 2 fc^y b US? 

(EDX, EAX) <D«-&fc>-£-ca>S. U5?X*4 
0 9 it, mmS^iii/h^*i:f*mA#l&/J^^»^^> 
W*Sr«jtt-f-*3t«><0 6 4 iTy b#»/h*;&«fcU5?;** 
(F (0) ) -C&£ 0 &m<OUi/X?<Dmi£ (designat 
ion) it, *«SWSrJ: <9a< H^-f-SJ: 5^K*+feH, 

[0035] *^y£ ' (SP* ) 4 1 111, 

H<D\sisX# (register) Sfctt 
US^^^a (registers) ^fflSrt&^ Ufc*»«r*0 5 
:t^U\ looafett, t^7VK^^ y^co 

[0 0 3 6 ] ro«j5feH:ffffl-rs»'&t>*>«^*T,ift>. 

[0037] *«w^v^< iti^nmm&tM'S, << 
T'vttt, m&vvtmtc&^xmrE'rZo 1 

oTV^ (inherently) *MC"Ca>'0 , lO/i:^ ^"^^ 

[ o o 3 8 ] »*uv^sii6ff'j^*5v^rtt, -o-^^y^ 

ITOS - t^yK^^^iM (TOS) i 
LT (for) S^d^Vi^^^ (register (s)) ICt&^^fu 

LTOS - TOSfcttfiMftASU^^ (regist 
er(s)) K**ft**t* 
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ftos - to si Lr»»«SB/j«jftSiii/i;^ 

^ (register (s) ) UlttHftSft* 

DTOS - TOS t IsX 

9 (register (s)) H*S*ASft£ 

VTOS - TOS^Saotr^l-^^ (register 
(s)) Kte&^ftTW^rfc&TF-f v o id TOS 
±E©i5lc, vto sttttttft!iottHlfcttJl*ij, 3te 

^ftmsftskt, >r v^^-y ^(ivTostt^kfdio 
[0 0 3 9 ] -f v*7°y #o»ftofett««r*ar*r 

fcSr^Sb^-TS (assist) fcfcUl, i5^$H5f> 

ft* 7>f-;i/K5 0 5, 5 0 7, 5 0 9 i£rttftr*) 
5o ^^^V— h^5 0 1 ii, 2 0 0&£8*.£ (over) 

i-*dfc*s-ct5ttftirfc* *»«*»t*<**t« 

k#;iibft£tl5#m^^a 5 ^£ftTV^ 0 

[0 04 0] {R3»-^->^«* (£*lte, ha-K)' 
f^i/-h*5 0 1 H^y^ttittSfei!) 

0 3*S|MT3ft*lfflG>* #»Sft-ci^**f 

tt««:*3W-r<5. wi*.rr, i stored b = — k 

^ v $ y $ ©*±ffiOfc»^SMf:asa>a r k 4:^ b 
i to sttttic-Y i^r^y *as*>s, it^M 
£ftrv>£ 0 -< v^y *j&s#f*bfcttttfc3m*fc:v^ 

a*, ba»u aT^»u<iaa*ft*'j: sic, 

[0 0 4 1 ] — A* K5 0 7fis <K2BH? , S'>"ft45 , 5 0 

3 £^T-r sfc#)^-r ^^y 

[0 0 4 2] ft«ttl, 7^^K5 0 9 11. iKffl"^^^ 
A* 5 0 3 SrlgfTUfcftO^V'^^y ^^4^1^: 
^t5„ Wxlf, I STORE^ha-Kd^ffJ 

y * ^aaEottffiiivTosrfcs. 
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[0 0 4 3] #* UV^JtffitPJKfc^TIi, 7^—^K5 
0 5tt, fiffl^^^^JStTSftSffl©, #tf$£ftT 

(Ha-^^^A^sitTSftfctto, -o^zry^o 

*ftrV^*y^V— hHfti5*fT*ft*lTOO, 

*^y *o:R1BW\ iSJB^^^A^oftfc)*) tc^r^v 

[0 0 4 4] f y/u- f*|:ov>tRM 

ba>b, w ^^y ( r^*/< 

) j&s, ^^u-haktt-frbXSJfflSftft. 
H6lt 0 3 tC^oT-O-^s/^^ft 

»t £ ft v 7 4 —A* K 6 0 5 , 607, 609, 611, 

*5J;W6 1 3 «rfttf?*-f x^y** 6 0 l oafcVSr"** 
"To 7^-/VK6 0 5tt, ITOSftH^ft^yf 
^ y^xWt*ftfc««-^^>-***rStffi-S-f v^^y 

-fl-" H*IC, 7^-/VK6 0 7, 6 0 

9, 6 11, *5J:V6 1 3fl, -tft-pft, LTOSft 
tt* FTOS^fii, DTOSftAU AJiaVTOSttll 
(DfttbcDsf ^^tt^tSft^iRffl-^^^A^SrJIfT 

^^y #<o«t«lcHaw*tfoftXV^4. 

[0045] ^^/y^tt, MWi:ttV7 h!?:rT 

Stff *ft*-<**^V h K* s , — fi., 
s/^£ft5k, -Tv^^y^lt, fto^fn-K (-< 
b b-C*Jffl*ftfc) k, y^y^oo^-y 
3^ftO7-f-^K6 0 5 v 6 0 7, 6 0 9, 6 1 

l, *5J:W6 l 3 z>5 fecoi oSrW^-f-*^ ^^7°y 9 

f sicss* nfcr Kv^^t y h sua. #*bv^n 
Jte#ju:*5^Ttt, f^^j/fSeoiii, ^^^^^ 
y ^ <DVtmtiib\C l ocd, ^-*7n^0 5oiLTS 
m^ftxi>^ 0 

[0 0 4 6 ] ^^^V— hftfciV^-f 

io^^ (*^»±, -^fttcov^rtt2o^®^6^) k 
b-c^m^ft^r k^*ct 6oiiRM»tfc« 0 bA^b 

50 ftfrbs »i bV^litWKtoV^Ttt, X^^U-h^io 
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^z/u— b*»±, *(i<>#jf}>*<o£f&wcm&-cmm 
*lt, tut, -r^^^y^ostfT^ic^rawufflSft 

[0 0 4 7 ] St, y^^U— b»*5J:V^-f ^^<s/^ 

^st^ut^^^t, ifo±5tc^*:^y 

71*, Jisf^V * £r£f#f 6 7°o-fe*£;^Utv^ e 
— t^7°ni?^|i, •*-^<t©iEffl^^^A^'*5 
J;tM ?°y * ^tt«l^«a^ Wi: ^ o t iff 
SnirlCtot, -f ^^y ^Irt^tSc Zfrft. A 
H^^S^/t (nested) /V— ^ >U—7\ 

[0 0 4 81 y^701ttt, nytfa-^ is* 7* 

t i isi^^ig-rr iiciot) 

So isXy'J*)*, 4ls#-?y #<D$tm&X J r 5/7*7 0 3 
^*5V^t3BRi-S. — <S3B"^'>^***5J;U c -f 

*^UtV>*tt*LiJ\ ^nJi^T 1 s^04*j£ 

[0 0 4 9 ] 5/^7 0 5 lC*5V^ttt* f^^tt, 

(legal) "C*>S*»*ra:3ei-S 0 JbfcSMSWUl*^ 

t, iiltR;**!,*:^ b = — KlC»f«>r 7*V * 
ft**b^*««r*S-rar ilCJ;-5taj5i)t*H*. am 

[0 0 5 0 ] JHf»Sft;M*tt*s Sft^hfcttfltfcJlfe 

5iUtt v Ihfi, r<3«*^J>frj&S#|Z'&ife (illega 

i) -ca>*r.i:«riK-ru4>*?feUftv\ ft*>*fc, ->* 

9 l" K** (corrupt) ^t^^v^ri: 
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jifettH^vTostfciitf, -O-^^y^tt, >^ey 
KttWSftt^aa-^^K;** y^rto*±ffi^— ^ 

ffl* 1 o£JL±<?5U^#rtlC»Ift-r4 <0J*.tf* SP' 

tJgU**^^— ^ffl«ru'i?^#K»*«abt, to 

ft* S P 1 £^W>b1-£) :^^oT, ITO 
S^cf^HSItm^o Ut, ■ 

[oo5i] — vto stttta»ktt*<0ftofl>tt 

tttc»!K ifctt, ftto|o««d»6VTOS^85 
©J;5*»» (shift) W\ ASWUtt, ^*yj6*bi 

[0 0 5 2] MSH/iifi^^^^J;^^^ 
y ^*t** s **fet v'*^*!**'^ 5/^7 0 7 

an »«*^-r ^"y ^ttttk**s*fetf, 

[0 0 5 3 ] 5/7*7 0 9 tC^oV^t, -f >- * 7° y 3&S 

*L^SMfc0fltC*$V^ttt-, EI 5 t^Sti/tfy/W'- b 
aSratRStLfcfiJB-^^^^fcffiv^t-f ^ ^^^t 

ttr 5 r 4: ^ <t o t ^ ^7°u- b B8*36S*V tti * ^ So 

[0054] r-^^^—vmmt, &iRZftftmi^*> 
ot$>55. ^i^^-^/!:^ pi-> »*bv^s^«^«■lJ^ci5v^ 

tli, f^^^v— x8 6-7^^p/pir;/f 

CO/^^)OC++^ Java ^7 ^ ^ ^"SIS t«**^t 
V^o ©LT^t*©* 5 ^ b ~ K I LO AD<Dfti£>CO 

50 ^^^ix- bBa*t*>a. 
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void TemplateTable: :lload(int n){ 

assembler, movl (eax, address (n)) ; 

} 

I LOAD^ y y Kft, Java {K^-^S/i^ifriHCtt: 
(for) TEMPLATE_TABLEtl?tf}l5^9 
XKMXsXlSmZftZo I LOAD^ha-Kli, * 

f^o MOVL^yyKtt, NOfltSr v^x#lc«< r. 

ASS EM B L E R^"^^^ £ h <Dft:#> ++K^-Cfc 
£o MOVLtt, J a v aM^'>VtHSfttfe$d5 

[0 0 5 5 ] Mo^tJi: UT, EAT«>fc«>tf\ '<>f h — 
K I ADD^ftOry/i/- h l9IS-C*)So 
void TemplateTable: :iadd0{ 
assembler, popl (edx); 
assembler, addl (eax, edx) ; 20 

} 

I ADD/ V y Ktt* J a v a ig3li"«r i/^O^^tCfi 
(for) TEMP LATE TAB LE£ P^fif ih/<5 & *7 

x\c&i,xmm£riz>o i add^m k©^»© 

(rftttx 8 6 W^n^ai^^-C^ES P=tf 
g^JCO (target) -^>T 9 n /a -fe ^ _btf>> * V ICftM 

^n-tv^s^co;*^ sx^ (H4 (b) isj^lIU 
(c) ofeflJSrJLJ;) t*5:klrI*t*©liUt 
&>3 0 ^coftisb, sp' ^IcJioTWUSSiftS 

fr'f? vy V h 
[ 0 0 5 6 ] n^0#^"C, >- sx £©*±tt: 

^^tC^SrcD^— EDXi:ft»SJl«. ADD 40 
5>*<0*±ffii: LT (for) V£?^^lCBfa 

Wp^lSiU, :^ft iK^/t^f iadd^ 

[ 0 0 5 7 ] Jb-cRWSJxfc J: 5 fcC, »* LV^*fc#]l£ 
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S^s^r-try-:/ y mt§ift coy y y Kt^tfT 

■fe^903fta!)^**^JS:Jbfrrx**^«. Sixers 

fc^o T-ti'-f r. ill, -0-*y° 

■fev^y»H-c»!&**b*r.i:^T* 

[0 0 5 8] 5/7*711 Ttt, S^f^tt, XI^P 

»o(E3B^^vA*«rsiffi-5^:«>ic-r yy 

[0 0 5 9 ] S^IC, ^BB-^©3ytf»-^3-K 

ffi^i/>ifo&<Dm'ff<v&<oi% J &<D'< is? yy #<Z>*t1lBj&S 
fc) b*»*©T\ *ofi*^iy^«*Sr*tTi-« J: 5tc 

>r y*yy *rt<z>te* (n^r— -> 3 ^) *ft^*r^>^^ 

ZsfyfX (XttteXyty b) feUT^PT^^o 3i 
[0 0 6 0] -y^^^ii, s//7on:ic5V^T>fy 

7 0l\cm*), ^LrXftl&miQ&ls (iteration) 
[0061] ^f5//7 0 5l:lot, 3MR*^3t<K3» 
*S*tyt*feli, ^X^J^^s ^fj//71 5^C*5V^•C 

(^y^r-fT, verifier) J; oT^tb ^H/t^7 

7 i s^M^i-rsr k ii, *»*H*r:t36s-ct <5. 

[0 0 6 2] B8fj:. /y ^ <Dft#><V J. n — ^ 

<o =3 s tf * - ^ = — K Sr f 5 y° a ir * £ * L T V ^ 



I 
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Zf7 1 1 fc*5V^£j58Stl,;&as ba> f d — ff<0 a 

sauTttK^ih**. x^y^8 o i ic*5v^rt, 

Ti/^A^Ot-fXtt, J a v a h a— K*C*5tf-* 
X^ySTJt (by) -f v# y * ^ h sttsr. 

[ 0 0 6 3 J — -§L ^t^ffi?©*^^^^^^^ 
^-KSr^riti-*. *©*7-fcyMl, He^^*^ 

* (subtable) fcttS^SrSHE-t-S. *ttt*fc*5tf*# 

«»»»t*s»t*»«#icj:<ftfe*fcv^4*< OSS 

[0064] y^8 0 SlCiol^Ttt, ^X^-Mi, 

>^^y>? e*Oa>'t^ — #=*— KrtlCT Kw^Srtt 
tc, j.trn— ^(oa^tf^—^a— Kii, twisty 
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[0 0 6 5] _fcia<Z>fc> **WO#*U^3SS6flTiJS: 

LTOS, FTOS, DTOS, VTOSO^Mb 
Tlofc£, £j»Sfrfc5 0©»JflilG>-f 7°y i^dSfc 

f^ixy#^^ 7°y ^^ffi^^^^< 
mitcfts-f v^^y fiaw*>r v#^y#±t) t 

[0 0 6 6 ] 0J 

**5J;^^ v#^y #tttt©ft**t?ii: (combinatio 
^ n) <oP ( g£:#C'* £ (through) ««U SJtll/i'— 

:^:j;ot, *r ^y # «r£j*i- s r. k as-c* % 0 

<fr:fc<ktM ^#^y #«tt^tt* (combination) co/t 

. [0 0 6 7 ] ^<Dm<om^, lADD/Vb=-btll 

a (pertain) f ^f^^ixf f 9 0 1 O^^/TttV^ 
5 e f-fX/Vf«©*ait H 6 Sr#8aurR913*b 
/ii^coirl^ b-C&£ 0 ^-T^tc, -f ^^s/^-att, {£ 

y^T'y #o#ttiB^ur i y a* k-c*>s, 

^ 7-f-AK9 0 5, 9 0 7, 9 0 9, 9 1 1 , *Sitf9 
1 3 Z^tto 

[0 0 6 8] I ADD/^ Kofe*© 1 0 

/!)^*ITOS«tt4btf, ^^Aitt» IAD 

>f^#^y#*5, -ttt-e^, LTOS, FTOS, DT 

os, VTOS^li:fc2>t#, a l > a f , a d , a v 

It, I ADD^V K =2— KSrSltT-rS^V^ /y 
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[0 0 6 9 ] <f 4 *y<i^*9 0 1 Kfctf 5 #W 
KO- igoir^ >-s y^or Kvx£r^Uft"o HlO 

3^1 0 0 3^, I ADD^VI K©35ff3>fc*<Z> 

■>3yi 0 0 3lt 2 00PO P Lift<££ 1 OOADD 

ITOS 

POPL EDX 

ADDL EAX,EDX 

<DISPATCH/ADVANCE> 

[0 0 7 2] fto&cDftisbltC, ^^y^^'ry^X. 

tfc6..POPL EAXIitSr^iy^titO^^y 
y $ frtbfflLl-X, t^^i?X^EAXlCS< 8 
(m 7 o^y-yfl 0 7 SrjLJ;) I ADD 
^-r h 3— K^tfti:M^^W-cfe^ ITOS^ 

shift) jfcfclC, /no^iUSrtS^o 
[ 0 0 7 3 ] POPL EDX**Jb*J;i;ADDLM 

AJ;) lc*5V^"cr^■fex*i^^^>'>^v— MM«ri ad 
D 0 ic J: oT£j« 

f a — ^o=i yt°a- ^ =3— K (l70Xf s//7 1 
lSrjLJ;) tfc5„ 3- Ko*t^ >3 vtt, StOOT 
irv^y-irff^^co^lCto-cm^^cD-C, ^ vt 0 ^ — 

[0 0 7 4 ] TOSVtm*tttt 
V T O S ttlllOV ^MCfc -w^aVlOO 
3 I ADD^W b 3 — K^rH^T-r^/tlftOs^t 0 ^ 

— 9 =*r- KSf&A/Ti^S. H 1 OlCa* 5 
9 (D-^-f ^^y^* 9 0 1 *»fc<Z>2tf>r ^ Avtt, 
■>3>1 0 0 3^^^ljlU ~<Dft#>, V 
TO SttH^fe I TO stt*^ ^ tl< (pu 

t) %}m4*&&n¥T£tiz. -r^^HsftsiTosR 

t^i/ 3 yi 003 2#§©A^4rigUf't-. 
^**ltv^ £ ^y^^y^j&ivTos^K/t 
ttlTOSttSlcfc^SiW^St, tf^^Aitc 

[0 0 7 5] *f 4 *'<5/^» 901 iCS^r* I ADD 
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[oo7o] -r^^y^^j***-, -fy^/y^iM 

TOS^yt(tVTOS«^lCfc^fcf , I ADD'V h 

[0 0 7 1 ] 

VTOS 

POPL EAX 

POPL EDX 

ADDL EAX, EDX 

<D ISP ATCH/ ADVANCE >„ 

yVh3-KlC»t5LTOS, FTOS, DTOSft 

TV**. SfclC, ^-TV^Al, Ap, AD^y^tt, ^ 

7-?:feIt5i 1 0 ^**lt6=s — ^ =2— KM 

^v- 3^1 005 LJg-To "fe ^ ^3^1 0 0 5 

a s #*«fc#lR (ia7o^5 1 ^^ , 7 i stlJ;) Kga^ 
*aa"t"4=» ytf»- ^ =3 — i oo-w^->3 vas^s 

*v^*fetf, *L0 aMWflSftJ&r. Id*. 
*=a— KM* S'g ft^cojil^icias^^ 
30 [0 0 7 6 ] LT^J\ 011 lw«SJi,« J; 

5u:io©K««F!ntaor, w v^y #«rflv^T<R» 

*> oJSffr s ^ a -fe x % R fl-r -5 w t lift tci: 

t^fc^f^/y^Md\ ^^^^y^SrH^-r^ 

^ [0 0 7 7 ] 101 tCiol^T, ayf^-^ 

&ja**vyw = ^tr * k) A^^^ffj^, 
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[0 0 7 8] tC&V^TT, S^^Att* 

[0 0 7 9 ]-!, aRSn^fiffl^^V*** 5 *^* 

nfcfe, -vx^-Mt x^s^i i o 5\cm^x&<o& jo 

ffltt, ^^.Mi, 1 0 7 tCioV^T^-f * 

sy^*^o*7-fe3x hSrlH»-J-6r ids-eft a. 

[0 0 8 0] 10 9tCjb h V^-C, */**rM'Z i f 

{Effl^^v-ft«S:*fT"t-«-f ^#^y ^Offi« (ta-Jr— 

f^^l 1 0 l^y'^f A^l^ 0 
[0081] ^^3/^1105, 1107, 1109 

o±;£*l::0 7 (DX'T yy°7 1 1 (C*5V^T^ fn- ?co 

— Klc*tJ&i-£. H l l -C7*£ti1t&9l<o9tmm<oWk 

S/*^Art x^s/r/i l o Qlcisv^T:^— 4: 
Z>fztb<D^ >-tf — KtCv^vt^r^o Stic* J- 

tit »*fcB8bT;fc*tt#»fc 

[0082] en 

*4r.ittWfe*»T*>a. #j;ut tzftztitzmnm 

It J a v a (R3B^->^Sr-< — </ h-f-;£^ h 
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«»0±git fc »;Wtfc#Iffll#©ifiH <im 

pendedclairas) £>3ft£ 5 *5J: tflKJM^ J; o X 

V\ 

[hi] ant *«w©nitw«>y y v Vx-r&nn 

[@2] 02lt Hi ^3yt°^-^i/^fA(7)y^f 

<0 J: 5 \c &ft £ *l 4 fa* 0 "C £> a . 

[04] 04 (a) ft y^^^gE^*?^, 
04 (b) It **W©^9VK^^ -y^Sr^i-*;S: 

affltt^^^^icttjwstbtv^a. 04 ( c ) it 

[05] 05lt -T>-^^y^^^. 

[06] sen, ^ v^^y +ic^j«*n45 f -f 

[07] B7tt, loEillov^^^ftjWS"^^ 

-r ^aMc-r isp^v? <^^m*mm trv^-< ^°y 

^ S: * jsgK -T 4 ^ a ir ^ 0 -c 4 o 

[08] B8lt -0-*y°V ? comft*y L y -7&£Wlr 

[09] B9lt ''W h =3 — K I AD D Sr^f *?" 6 /t^> 
^0 6 co^>r ^^^y^*H<o«B»Sr^i-«-8:H"Cfc*- 
[010] 01 OH, -E^^^^Sr^tTb. 

[ill] lit *«Wo3S«SOT*ctt 5 , Jisf? 

^Pir^0-Cfc^ o 
[^^ISl^] 

1 —=a ^t"^. — 3-7 f ^^/l/'f , 5-^ 
^y->, 7-^^tf^^ 9-^r-^-K, 11- 
•^^X, ,13, 1 5 1—* 

5 7-y A-^^yHE«3Sfi, 
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6 5 — ^ s/f!7-^^^7x-^, 10 1— Java 
y — ^=J— 10 3-/Wf3-KaWW? 4 10 
5"-Java^^^yr-<^N 107 --Java 

2 0 1, 3 0 1 , 4 0 1 
2 0 3, 3 0 3, 4 0 3 2 0 5, 3 0 7, 4 

1 1 y^atf-f (SP) , 305, 405. 4 

0 7, 4 0 9 — 
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5 0 , 5 0 3-^ 

ha^Kv 5 0 5, 5 0 7, 5 0 9 — 7 -f — A* K, 60 
1 —^-Y f-tt % 6 0 3-fi?@^'»#^ 6 0 

5, 607, 609, 611, 6 1 3 — 37 -< — ;V K, 9 
Ol-^^iyf^ 9 0 3 "-{SSS*^^^^, 9 0 
5, 907, 909, 911, 9 1 3-7>f-AK, 1 
0 0 3, 1 0 0 5—ir^->-3 >\ 



[HI 1 



[02] 




5K 



55 



EE 



A' 



CtSttS 











^•>x 




xtr— * 







[B3 ] 



[B4] 



2^ 



JAVA V — Xa — K 



public class HetloWorWj 
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1. Title of Invention 

INTERPRETER GENERATION AND 
IMPLEMENTATION UTILIZING 
INTERPRETER STATES AND REGISTER 
CACHING 

2, Claims 

1 . In a computer system including a plurality of registers, a method for 
implementing an interpreter including an operand stack having a top, the method 
comprising: 

storing a value for the top of the operand stack in at least one register of the 
plurality of registers; and 

utilizing a state of the interpreter to indicate a data type of the value for the top of 
the operand stack that is stored in the at least one register. 

2. The method of claim 1, wherein the data type is selected from the group 
consisting of integer, long integer, single-precision floating point, and double-precision 
floating point. 

3. The method of one of claims 1 or 2, wherein the data type is void to 
indicate that the value for the top of the operand stack is not currently stored in the at least 
one register. 

4. The method of one of claims U3, wherein an instruction that utilizes the 
top of the operand stack accesses the at least one register. 

5. The method of one of claims 1 -4, wherein the plurality of registers includes 
at least two registers that are used for storing values of different data types. 

6. The method of one of claims 1-5, wherein the data type indicated by the 
state of the interpreter specifies the at least one register of the plurality of registers that 
stores the top of the operand stack. 
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7. The method of one of claims 1-6, wherein the interpreter is a Java virtual 
machine. 

8. In a computer system including a plurality of registers, a method for 
generating an interpreter that stores a value for a top of an operand stack in the at least one 
register, the method comprising: 

selecting a virtual machine instruction to be interpreted by the interpreter; 

selecting a state of the interpreter, wherein the state of the interpreter indicates a 
data type of the value for the top of the operand stack that is stored in at least one register 
of the plurality of registers; 

generating computer code for the interpreter to put the interpreter in an expected 
state for the selected virtual machine instruction if the selected state differs from the 
expected state; and 

generating computer code for the interpreter to execute the selected virtual 
machine instruction. 

9. The method of claim 8, wherein the expected state for the selected virtual 
function is obtained by accessing a table indexed by virtual machine instructions that 
stores expected states of the interpreter before execution of the virtual machine 
instructions. 

10. The method of claim 9, wherein the table stores current states of the 
interpreter after execution of the virtual machine instructions. 



1 1 . The method of claim 9, wherein the table stores pointers to functions that 
generate computer code for the interpreter to execute the virtual machine instructions. 
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12. The method of one of claims 8-11, wherein the computer code for the 
interpreter to execute the selected function is generated by calling a function specified in a 
table indexed by virtual machine instructions that stores pointers to functions that generate 
computer code for the interpreter to execute the virtual machine functions. 

13. The method of one of claims 8- 1 2, further comprising generating computer 
code for the interpreter to fetch the next virtual machine instruction. 

1 4. The method of one of claims 8-13, further comprising generating computer 
code for the interpreter to jump to a location in the interpreter that executes the next 
virtual machine instruction for a current state of the interpreter after execution of the 
selected virtual machine instruction. 

15. The method of one of claims 8-14, wherein the location in the interpreter 
handles an error if the selected virtual machine instruction is illegal for the selected state. 

16. The method of one of claims 8-15, wherein the interpreter is a Java virtual 
machine. 



3. Detailed Description of Invention 
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The Java virtual machine is commonly implemented as an software interpreter. 
Conventional interpreters decode and execute the virtual machine instructions of an 
interpreted program one instruction at a time during execution. Compilers, on the other 
hand, decode source code into native machine instructions prior to execution so that 
decoding is not performed during execution, Because conventional interpreters decode each 
instruction before it is executed repeatedly each time the instruction is encountered, 
execution of interpreted programs is typically quite slower than compiled programs because 
the native machine instructions of compiled programs can be executed on the native machine 
or computer system without necessitating decoding. 

As a software interpreter must be executing in order to decode and execute an 
interpreted program, the software interpreter consumes resources (e.g., memory) that will 
therefore no longer be available to the interpreted program. This is in stark contrast to' 
compiled programs that execute as native machine instructions so they may be directly 
executed on the target computer and are therefore generally free to utilize more resources 
than interpreted programs. 

Accordingly, there is a need for new techniques for increasing the execution speed 
of computer programs that are being interpreted Additionally, there is a need to provide 
interpreters that are efficient in terms of the resources they require, 



(21) WIHT 1 1-85534 

SUMMARY OF THE INVENTION 
In general some embodiments of the present invention provide innovative systems 
and methods for increasing the execution speed of computer programs executed by an 
interpreter. The interpreter includes an operand stack that is utilized to execute the virtual 
machine instructions. The value for the top of the operand stack is stored in one or more 
registers which allows the execution speed of stack-based virtual machine instructions to be 
increased. A state of the interpreter is utilized to indicate the data type of the value for the 
top of the operand stack stored in the one or more registers, "With the invention, the 
programs may be interpreted in a more efficient manner utilizing registers. Additionally, the 
size of the interpreter may kept small which allows more resources to be available for the 
interpreted program. Several embodiments of the invention are described below. 

In one embodiment, a computer implemented method for implementing an 
interpreter including an operand stack is provided. A value for the top of the operand stack 
is stored in at least one register of the computer instead of on the stack. Many conventional 
computers have registers for storing different data types. Accordingly, the value for the top 
of the stack is stored in one or more registers appropriate for its data type and the state of the 
interpreter is utilized to indicate the data type of the value for the top of the operand stack 
that is stored in the one or more registers. In preferred embodiments, the interpreter is a 
Java virtual machine and the states of the interpreter may include integer, long integer, 
single-precision floating point, and double-precision floating point. 

In another embodiment, a computer implemented method for generating an 
interpreter that stores a value for the top of an operand stack in one or more registers is 
provided. The state of the interpreter indicates a data type of the value for the top of the 
operand stack that is stored in the one or more registers. In order to generate the interpreter, 
the computer may loop through all the possible virtual instructions and states of the 
interpreter. In each iteration, a virtual machine instruction and a state of the interpreter may 
be selected. If the selected state differs from the state of the interpreter that is expected prior 
to the execution of the selected virtual machine instructions, computer code for the 
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interpreter is generated to put the interpreter in the expected state. Once it is known that the 
interpreter is in the expected state prior to the execution of the selected virtual machine 
instruction, computer code for the interpreter is generated to execute the selected virtual 
machine instruction. The expected state for the selected virtual machine instruction may be 
obtained by accessing a table indexed by virtual machine instructions thai stores expected 
states of the interpreter before execution of the virtual machine instructions and current states 
of the interpreter after execution of the virtual machine instructions. Additionally, the 
computer code for the interpreter to execute the selected virtual machine instruction may be 
generated by calling a function specified in the table. 

In another embodiment, a data structure stored by a computer readable medium for 
an interpreter of virtual machine instructions is provided. The data structure is a table 
indexed by virtual machine instrucdons and having multiple fields. In one field of the table, 
expected states of the interpreter before execution of the virtual machine instructions axe 
stored. In another field of the table is stored current states of the interpreter after execution 
of the virtual machine instructions. Additionally, a field of the table may be udlized to store 
pointers to functions that generate computer code for the interpreter to execute the virtual 
machine instructions. In a preferred embodiment, a state of the interpreter indicates the data 
type of a value for the top of an operand stack of the interpreter that is stored in one or more 
registers. 

In another embodiment, a data structure stored by a computer readable medium for 
an interpreter of virtual machine instructions is provided. The data structure is a table 
indexed by virtual machine instructions and having multiple fields, each field being 
associated with a state of the interpreter and storing a pointer to a location in the interpreter 
that executes the indexed virtual machine instructions. The state of the interpreter may 
indicate the data type of a value for the top of an operand stack of the interpreter that is 
stored in one or more registers. In preferred embodiments, the state of the interpreter may 
be integer, long integer, single-precision floating point, and double-precision floating point. 

Other features and advantages of the invention will become readily apparent upon 
review of the following detailed description in association with the accompanying drawings. 
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DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

Definitions 

Machine instruction - An instruction that directs a computer to perform an operation 
specified by an operation code (opcode) and optionally one or more operand. 

Virtual machine instruction - A machine instruction for a software emulated 
microprocessor or computer architecture (also called virtual code). 

Native machine instruction - A machine instruction that is designed for a specific 
microprocessor or computer architecture (also called native code). 

Class - An object-oriented data type that defines the data and methods that each 
object of a class will include. 

Function - A software routine (also called a subroutine, procedure, member 
function, and method). 

Operand stack - A stack utilized to store operands for use by machine instructions 
during execution. 

Bytecode pointer (BCP) - A pointer that points to the current Java virtual machine 
instruction (e.g., bytecode) that is being executed. 

Program counter (PC) - A pointer that points to the machine instruction (typically 
native) of the interpreter that is being executed. 

Interpreter - A program in software or hardware that typically translates and then 
executes each instruction in a computer program. 

Interpreter generator - A program in software or hardware that generates an 
interpreter. 

Overview 

In the description that follows, the present invention will be described in reference to 
a preferred embodiment that implements a Java virtual machine for executing Java virtual 
machine instructions (bytecodes). In particular, examples will be described including native 
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machine instructions of IBM personal computers (Intel x86 microprocessor architectures). 
However, the invention is not limited to any particular language, computer architecture, or 
specific implementation. Therefore, the description of the embodiments that follow is for 
purposes of illustration and not limitation. 

Fig. 1 illustrates an example of a computer system that may be used to execute the 
software of an embodiment of the invention. Fig. 1 shows a computer system 1 which 
includes a display 3, screen 5, cabinet 7, keyboard 9, and mouse M'. Mouse 1 1 may have 
one or more buttons for interacting with a graphical user interface. Cabinet 7 houses a CD- 
ROM drive 13, system memory and a hard drive (see Fig. 2) which may be utilized to store 
and retrieve software programs incorporating computer code that implements the invention, 
data for use with the invention, and the like. Although the CD-ROM 15 is shown as an 
exemplary computer readable storage medium, other computer readable storage media 
including floppy disk, tape, flash memory, system memory, and hard drive may be utilized. 
Additionally, a data signal embodied in a carrier wave (e.g., in a network including the 
Internet) may be the computer readable storage medium. 

Fig. 2 shows a system block diagram of computer system 1 used to execute the 
software of an embodiment of the invention. As in Fig. 1, computer system I includes 
monitor 3 and keyboard 9, and mouse 1 1. Computer system 1 further includes subsystems 
such as a central processor 51, system memory 53, fixed storage 55 (e.g., hard drive), 
removable storage 57 (e.g., CD-ROM drive), display adapter 59, sound card 61, speakers 
63, and network interface 65. Other computer systems suitable for use with the invention 
may include additional or fewer subsystems. For example, another computer system could 
include more than one processor 51 (i.e., a multi-processor system), or a cache memory. 

The system bus architecture of computer system 1 is represented by arrows 67. 
However, these arrows are illustrative of any interconnection scheme serving to link the 
subsystems. For example, a local bus could be utilized to connect the central processor to 
the system memory and display adapter. Computer system 1 shown in Fig. 2 is but an 
example of a computer system suitable for use with the invention. Other computer 
architectures having different configurations of subsystems may also be utilized. 
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Typically, computer programs written in the Java programming language are 
compiled into bytecodes or Java virtual machine instructions which are then executed by a 
Java virtual machine. The bytecodes are stored in class files which arc input into the Java 
virtual machine for interpretation. Fig. 3 shows a progression of a simple piece of Java 
source code through execution by an interpreter . the Java virtual machine. 

Java source code 101 includes the classic Hello World program written in Java. The 
source code is then input into abytecode compiler 103 which compiles the source code into 
bytecodes. The bytecodes are virtual machine instructions as they will be executed by a 
software emulated computer. Typically, virtual machine instructions are generic (i.e., not 
designed for any specific microprocessor or computer architecture) but this is not required. 
The bytecode compiler outputs a Java class file 105 which includes the bytecodes for the 
Java program. 

The Java class file is input into a Java virtual machine 107. The Java virtual 
machine is an interpreter that decodes and executes the bytecodes in the Java class file. The 
Java virtual machine is an interpreter, but is commonly referred to as a virtual machine as it 
emulates a microprocessor or computer architecture in software (e.g., the microprocessor or 
computer architecture that may not exist in hardware). 

An interpreter may execute a bytecode program by repeatedly executing the 
following steps: 

Execute - execute operation of the current bytecode 

Advance - advance bytecode pointer to next bytecode 

Dispatch - fetch the bytecode at the bytecode pointer and jump to the implementation 
(i.e., execute step) of that bytecode. 
The execute step implements the operation of a particular bytecode. The advance step 
increments the bytecode pointer so that it points to the next bytecode. Lastly, the dispatch 
step fetches the bytecode at the current bytecode pointer and jumps to the piece of native 
machine code that implements that bytecode. The execution of the execute-advancc-dispatch 
sequence for a bytecode is commonly called an "interpretation cycle." 
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Although in a preferred embodiment, the interpreter utilizes the interpretation cycle 
described above, many other interpretation cycles may be utilized in conjunction with the 
present invention. For example, an interpreter may perform dispatch-c^ecute-advance 
interpretation cycles or there may be more or fewer steps in each cycle. Accordingly, the 
invention is not limited to the embodiments described herein. 

Java Virtual Machine Implementation and Generation 

The virtual machine instructions for the Java virtual machine include stack-based 
instructions. Thus, one or more of the operands of the virtual machine instructions may be 
stored in an operand stack. Before describing the operand stack, it may be beneficial to 
discuss a general stack. 

Fig. 4A shows a stack 201 that stores data 203. With the stack, a data value may 
be "pushed" onto the top of the stack. Alternatively, a data value may be "popped" off the 
top of the stack. Conceptually, only the top of the stack may be accessed so the stack is 
known as a first in, first out (FIFO) data structure meaning that the data that was most 
recently pushed onto the stack will be the first data to be popped off the stack. A stack 
pointer (SP) 205 points to the top of stack 20 1 . Thus, the SP will change as data values are 
pushed onto and popped off the stack. For simplicity, the stacks described herein are 
shown and described as growing upwards in memory; however, this is just a graphical 
representation and those of skill in the art will readily recognize that a stack may be shown 
and/or implemented in many other ways (e.g., growing downwards in memory). 

The virtual machine instructions for the Java virtual machine call for an 
implementation of an operand stack that may be similar to the stack shown in Fig. 4A. 
More specifically, the operand stack in the Java virtual machine is utilized to store operands 
for use by the bytecodes during execution. The following is an example that may help 
illustrate how an operand stack is utilized in the Java virtual machine. 

Assume that the Java source code includes a statement X:=A+B, where X, A and B 
are integer variables. This statement may be compiled into the following bytecodes: 
l.ILOAD A 
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2.ILOADB 

3. IADD 

4. 1STORE X 

It should be noted that the T T preceding each bytecode indicates that the data type of the 
values manipulated by the bytecodes are integers. There are corresponding bytecodes for 
other data types which are designated by an **L" for long integer, "F* for single-precision 
floating point, and **D M for double-precision floating point. In the Java virtual machine, the 
integer data type is 32 bits, long integer data type is 64 bits, the single -precis ion floating 
point datatype is 32 bits, and the double-precision floating point data type is 64 bits. As 
will be illustrated below, the size of these data types in the virtual machine may not be the 
same as in the computer system implementing the virtual machine (e.g., the standard integer 
data type on an IBM personal computer is 16 bits and there is no direct support for 64~bit 
long integers), so it is important to make a distinction between the Java virtual machine 
instructions and the native machine instructions that direct the computer on which the virtual 
machine is implemented. 

The first ILOAD by tecode loads the value of variable A onto the operand stack. 
Similarly, the second ELOAD by tecode loads the value of variable B onto the operand stack. 
The bytecode IADD pops two data values off the operand stack, adds the two values and 
pushes the sum onto the operand stack. As may be expected, the ISTORE bytecode pops a 
data value off the operand stack, the sum in this case, and stores it in variable X. This 
simple example illustrates conceptually how Java bytecodes utilize an operand stack. 

Some embodiments of the present invention take advantage of the fact that 
oftentimes when a data value is pushed onto the operand stack, it will subsequently be 
popped off the operand stack (with or without intervening bytecodes that do not modify the 
top of the operand stack). Typically, the operand stack is implemented in memory but with 
some embodiments of the present invention, the value for the top of the operand stack is 
stored in one or more registers. As registers have a faster access time than memory, access 
time for the top of the operand stack may be decreased resulting in faster interpretation of 
the interpreted program. 
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Fig. 4B shows an operand stack 301 that stores data 303. Data 303 includes both 
data values in memory and a data value for the top of the operand stack stored in a register 
305. A stack pointer* (SP-) 307 points to the data value conceptually just below the top of 
operand stack 301 . It should be noted that this discussion focuses on a single operand 
stack- However, there may be multiple operand stacks in a single computer system (e.g., 
for different threads and methods) which may implemented according to the present 
invention. 

Conventional computer systems typically have many different registers, with certain 
registers being better suited to store specific data types. For example, a computer may have 
registers that are 32 bits wide and registers that are 64 bits wide, If an integer on this 
hypothetical computer is a 32 bit quantity while a long integer is a 64 bit quantity, it would 
be more efficient to store the data values in a register that matches the size of the data value. 
Furthermore, computer systems may have registers that are designed to store specific data 
types like single-precision floating point or double-precision floating point 

More specifically, the IBM personal computers (Intel x86 architectures) include 
many different types of registers. There are 32 bit registers (e.g., EAX) and floating point 
registers (e.g.. F(0)). Additionally, some of the data types of Intel x86 microprocessors 
have different sizes then their counterparts in the Java virtual machine. For example, a 
standard integer data type is 16 bits wide and a long integer data type is 32 bits wide in an 
Intel 80386 microprocessor. These data types are half the size of their Java virtual machine 
counterparts. Accordingly, in preferred embodiments where the Java virtual machine is 
implemented on an x86 machine, an integer in the Java virtual machine is the same size as a 
long integer in the x86 machine (i.e., both are 32 bit quantities). 

As mentioned previously, it is important to keep in mind whether an instruction is a 
virtual machine instruction or a native machine instruction. Although the Java virtual 
machine instructions look similar to assembly language, fortunately there is an easily 
recognizable difference. In the bytecodes described herein for the Java virtual machine, the 
data type for which the bytecodes pertain precedes the instruction (e.g., ISTORE where the 
4 T* designates integer). This is in stark contrast to the assembly code (or native machine 
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instructions) for the x86 microprocessors where the data type follows the instructions (e.g., 
POPL where the "L w designates long integer). Although this will likely not be true for all 
embodiments of the invention, it is hoped that this distinction will aid the reader's 
understanding of the preferred embodiments described herein. 

Returning briefly to Fig. 4B, there is a problem since there is only one register 
shown and operand stack 301 may be utilized to store different data types so it would be 
desirable to have different registers available to store the value for the top of the operand 
stack. Fig. 4C shows an operand stack 401 for a Java virtual machine implemented on an 
x86 microprocessor . Operand stack 401 stores data 403 which includes both data values in 
memory and a data value for the top of the operand stack stored in one of registers 405, 407 
or 409. In a preferred embodiment, register 405 is a 32 bit register (EAX) for storing « 
virtual machine integers for the top of the operand stack. Register 407 is a combination of 
two 32 bit registers (EDX:EAX) for storing virtual machine long integers for the top of the 
operand stack. Register 409 is a 64 bit floating point register (F(0)) for storing both single- 
precision floating point and double-precision floating point. The designation of specific 
registers is provided to better illustrate the invention; however, it should be understood that 
the present invention is not limited to any specific registers or computer architectures. 

A stack pointer* (SP*) 411 points to the data value conceptually just below the top of 
operand stack 401. Now that there is more than one register that may be storing the value 
for the top of the operand stack, it would be desirable to know which register or registers 
stored this value. One technique would be to store a value in memory or a register 
indicating the data type of the Yalue on the top of the operand stack. Accordingly, this could 
be accessed to determine the right register or registers storing the top of the operand stack. 

Although this technique may work, it has some significant drawbacks that may 
make it unsatisfactory. For example, the extra determination of the data type of the top of 
the operand stack may offset the performance increase of utilizing registers to store the top 
of the operand stack. 

With some embodiments of the present invention, the interpreter operates in multiple 
states. Each state indicates the data type of the value of the top of the operand stack stored 
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in the one or more registers. The state is an inherent quality of the interpreter at any point in 
time so a determination of the data type of the top of the operand stack is-not required. 

In a preferred embodiment, the interpreter may be in one of five different states as 
follows: 

]TOS - an integer for the top of the operand stack (TOS) is stored in registers) 

LTOS - a long integer for the TOS is stored in registers) 

FTOS - a single-precision floating point for the TOS is stored in register(s) 

DTOS - a double-precision floating point for the TOS is stored in register(s) 

VTOS - void TOS, meaning the TOS is not currently stored in register(s) 
As indicated above, the VTOS state is different from the rest of the states because it 
indicates that the top of the operand stack is not currendy stored in any of the registers. It 
should be apparent that as data values are pushed onto and popped off of the operand stack, 
the interpreter may alternate between the VTOS state and one of the other states. 

In order to assist in managing the different states of the interpreter, a template table 
(data structure) 501 shown in Fig. 5 is utilized in some embodiments of the invention. 
Template tabic 501 is a table that is indexed by bytecodes 503 and includes fields 505, 507, 
and 509. Although template table 501 may have over two hundred records (e.g., one for 
each bytecode), only a subset are shown which are thought to best illustrate the invention. 

The virtual machine instructions (or bytecodes) are utilized to index the template 
table 50 1 . Field 505 stores the state of the interpreter that is expected before virtual machine 
instrucdons 503 execute. For example, before an ISTORE bytecode is executed (i.e., store 
the integer on the top of the operand stack), it is expected that the interpreter will be in the 
FTOS state indicating that there is an integer for the top of the operand stack stored in the 
one or more registers. If the interpreter is not in the expected state during execution, that 
does not necessarily indicate there is an error, but as will described in more detail below, 
preferred embodiments of the invention are able to detect many errors in the bytecode 
sequence. 

Field 507 stores pointers to functions that generate computer code (or a "template" 
and hence template table") for the interpreter to execute virtual machine instructions 503. 
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In a preferred embodiment, the names of the functions are the same as the name of the 
bytecodes and the functions are written in the C++ programming language. 

Lastly, field 509 stores the current state of the interpreter after execution of virtual 
machine instructions 503. For example, after an ISTORE bytecode is executed, the current 
state of the interpreter would be VTOS since the integer stored in the one or more registers 
has been popped off the operand stack. 

In preferred embodiments, field 505 stores the state of the interpreter that is expected 
before a virtual machine instruction executes and field 509 stores the current state of the 
interpreter after the virtual machine instruction executes. However, in other embodiments 
field 505 stores the state of the interpreter that is expected before the template function 
specified in field 507 executes and field 509 stores the current state of the interpreter after 
the template function executes. In other words, the state of the interpret may be based on 
the template functions instead of the virtual machine instructions. 

The template table has been described but during interpreter generation, another table 
(the "dispatch table") is utilized in conjunction with the template table. Fig. 6 shows a 
layout of a dispatch tabic 601 which is indexed by virtual machine instructions 603 and 
includes fields 605, 607, 609, 61 1, and 613. Field 605 stores pointers to a location or 
address in the interpreter that executes the indexed virtual machine instructions for the UOS 
state. Similarly, fields 607, 609, 611, and 613 store pointers to a location or address in the 
interpreter that executes the indexed virtual machine instructions for the LTOS, FTOS, 
DTOS, and VTOS states, respectively. Accordingly, each field is associated with a state of 
the interpreter. The values of the fields are not shown as they are pointers to within a 
generated interpreter. 

Recalling that the interpreter is typically a software program itself, the dispatch table 
is a jump table to different locations within the computer code of the interpreter program. In 
other words, once the next bytecode to be executed is fetched, the interpreter jumps to the 
location indicated in the dispatch table specified by the next bytecode (utilized as an index) 
and the current state of the interpreter which specifies one of fields 605, 607, 609, 61 1, or 
613 for the location of the jump. Thus, the program counter of the interpreter is set to the 
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specified address in the dispatch table. In a preferred embodiment, dispatch table 60 1 is 
implemented as five single-dimensional tables, one for each interpreter state. 

It should be apparent that the template table and the dispatch table may be 
implemented as one table (or more than two tables for that matter). However, in preferred 
embodiments, the template table and dispatch table are separate tables as the template table 
may be utilized solely during interpreter generation and therefore may be discarded after the 
interpreter is generated. The dispatch table is generated or filled during interpreter 
generation and advantageously utilized during interpreter execution. Nevertheless, the 
information in these tables may be implemented in any number of ways in any number of 
data structures known to those of skill in the art. 

Now that the template and dispatch tables have been described, it may be appropriate 
to describe how the interpreter may be generated. Fig. 7 shows a process of generating an 
interpreter. In general, the process generates the interpreter by cycling through all the 
virtual machine instructions and interpreter state combinations. This may be implemented 
with nested loops, a single loop or other control structures. In a preferred embodiment, 
nested loops arc utilized. 

At step 701, the computer system selects a virtual machine instruction (e.g., by one 
iteration through a loop through the virtual machine instructions). The system selects an 
interpreter state at step 703. Once a virtual machine instruction and an interpreter state are 
selected, the rest of the process in Fig. 7 generates computer code for the interpreter that 
will handle the selected virtual machine instruction when the interpreter is currently in the 
selected state. Although the drawings show flowcharts for embodiments of the invention 
for purposes of illustration, no specific ordering or combination of steps should be implied. 
In general, steps may be reordered, combined or deleted without departing from the scope 
of the invention. 

At step 705, the system determines if the selected virtual machine instruction and 
interpreter state are legal. In one embodiment, this is accomplished by determining the 
expected state of the interpreter for the selected bytecode utilizing the template table (see Fig. 
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5). If the expected state is the same as the selected state, then the combination of selected 
virtual machine instruction and state is legal. 

If the expected state is different from the selected state, this does not necessarily 
mean that the combination is illegal. Instead, the system determines if there is a legal way 
(meaning that does not corrupt the operand stack) from the selected state to the expected 
state. For example, if the expected state is ITOS and the selected state is VTOS, the 
interpreter may be put in the ITOS state by moving the top data value in the operand stack 
that is stored in memory into one or more registers (e.g., store the data value pointed to by 
SP 1 into a register and then decrement SP*). As another example, if the expected state is 
ITOS and the selected state is DTOS, there is no legal way to put the interpreter in the ITOS 
state since the top of the operand stack currently is a double-precision floating point. 

In general, it is legal to go from the state of VTOS to any other state or to go from 
any other state to VTOS. The reason is that these shifts of interpreter state typically include 
moving a data value from memory to one or more registers, or vice versa. 

If the selected virtual machine instruction and interpreter state are legal, the system 
may generate prolog computer code at step 707. The prolog computer code is any code that 
would be advantageously generated before execution of the selected virtual machine 
instruction. In general, the prolog may depend on the selected virtual machine instruction 
and the selected interpreter state. For example, if the expected state of the interpreter (for 
the selected virtual machine instruction) is different than the selected interpreter state, the 
prolog may include computer code to put the interpreter in the expected state. If the 
expected and selected states of the interpreter are the same, it may not be necessary to 
generate prolog computer code. 

At step 709, the system calls the template function for the selected virtual machine 
instruction in order to generate computer code for the interpreter to execute the selected 
virtual machine instruction, 3n a preferred embodiment, the template function is called by 
indexing the template table shown in Fig. 5 with the selected virtual machine instruction. 
The field, field 507 > which stores the pointer to (or address for) the template function is then 
accessed and the template function is called. 
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The template function generates computer code to execute the selected virtual 
machine instruction. It may be helpful to discuss a few examples of template functions. 
As mentioned earlier, in a preferred embodiment the template functions arc written in the 
C++ and Java programming languages for an x86 microprocessor. The following is a 
template function for the bytecode ELOAD: 

voidTemplateTable::iload(intn) ( 

assembler.rnovI(eax, address(n)); 

) 

The ILOAD method is defined for a class called TEMPLATES ABLE for the Java virtual 
machine. As the DLOAD bytecode pushes an integer onto the operand stack, the template 
function by the same name has a parameter mat is an integer. The MOVL method is a C++ 
function for an ASSEMBLER object that pushes the value of N onto the operand stack~by 
placing it in a register. Recall that MOVL corresponds to the x86 assembly language 
instruction that moves a 32 bit quantity which is an integer in the Java virtual machine 
instruction but a long integer in the x86 microprocessor. 

As another example, the following is a template function for the bytecode I ADD: 

voidTemplateTable::iaddO ( 
assembler.popl(edx) ; 
assembler.addl(eax, edx); 

) 

The IADD method is defined for a class called TEMPLATEJTABLE for the Java virtual 
machine. The expected state for the IADD bytecode is UOS so there should be an integer at 
the top of the operand stack stored in a register (EAX in this example). First, the value 
pointed to by the SP* pointer (which may be the ESP pointer in the x86 microprocessor) is 
popped ofF the stack utilizing the POPL method. It is important to understand that the stack 
we are discussing now is the native stack stored in memory on the target microprocessor 
(see left side of Figs. 4B and 4C). Thus, the data value pointed to by the SP' pointer is 
moved into the register EDX and SP' is then decremented. 
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At this point, the top of the operand stack is stored in the register EAX and the next 
highest data value on the operand stack is stored in EDX. The ADDL method corresponds 
to an assembly language instruction that adds the values stored in EAX and EDX, storing 
the sum in EAX. The EAX register now stores the desired sum in the appropriate register 
for the top of the operand stack, meaning the interpreter is now in the ITOS state as 
specified in the template table of Fig. 5 following the execution of the selected function 
IADD: 

As illustrated above, in preferred embodiments, an object is instantiated for the 
assembler which includes methods for each assembly language instruction that will be 
utilized in the interpreter. For simplicity, the names of the methods are the same as the 
assembly language instructions. It has been found that utilizing an assembler object is 
beneficial for generation of the interpreter because an extra assembler need not be utilized. 
In some embodiments, the template functions may be written in assembly language for the 
desired computer architecture. 

At step 711, the system generates epilog computer code. The epilog is computer 
code that sets up the interpreter to execute the next virtual machine instruction. Thus, the 
epilog performs the advance and dispatch steps of the interpreter described earlier. 

Initially, the prolog computer code fetches the next virtual machine instruction. 
Since the current state of the interpreter after the execution of the selected virtual machine 
instruction is known (e.g., from field 509 of the template table in Fig. 5). the next virtual 
machine instruction may be utilized as an index (or offset) into the dispatch table of Fig. 6 in 
order to determine the location within the interpreter to execute the next virtual machine 
instruction. The computer code in the epilog will be discussed in more detail in reference to 
Fig. 8, but in general, the epilog depends on the selected virtual machine and the current 
interpreter state. 

The system determines if there are more virtual machine instruction/interpreter states 
for which to generate computer code for the interpreter at step 701. If there are the process 
returns to step 701 and performs another iteration. 
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Back at step 705 if it is determined that the selected virtual machine instruction and 
interpreter state are illegal, the system may generate computer code to handle the error at 
step 715. Generally speaking, the error is an illegal bytecode sequence. In a preferred 
embodiment, computer code is generated for the interpreter that jumps to instructions that 
inform the user that this error has occurred. Although the number of errors detected in this 
manner will not be as numerous as those detected by a bytecode verifier, it may be desirable 
especially if one is not required or able to use a bytecode verifier. In some embodiments, 
the error checking and handling steps 707 and 715 may be omitted. 

Fig. 8 shows a process of generating the epilog computer code for the interpreter. 
The epilog computer code is generated at step 711 of Fig. 7, but a specific embodiment that 
generates the epilog computer code will be discussed in reference to Fig. 8. At step 801, 
computer code that fetches the next virtual machine ins miction is generated. The next 
virtual machine instruction may be fetched by incrementing the current bytecode pointer to 
the next bytecode and then fetching the bytecode pointed to or referenced by the bytecode 
pointer. As the size of. the virtual machine instructions may vary as in the case of Java 
bytecodes, in a preferred embodiment a table is utilized to store the size of each bytecode so 
that the bytecode pointer may be incremented by the size in the table to point to the next 
bytecode. 

Once the next virtual machine instruction is fetched, the system generates computer 
code to calculate an offset into the dispatch table at step 803. The offset is the number 
which when added to the starting address of the dispajch table of Fig. 6 results in the field 
indexed by the next bytecode and the current interpreter state. In a preferred embodiment, 
the dispatch table includes five single-dimensional tables (or sub tables), one for each 
interpreter state. The current state of the interpreter determines which subtablc to utilize. 
The size of each field in the subtables may be a fixed size (e.g., four bytes) so calculating 
the offset includes multiplying the next bytecode value by the fixed size. In other 
embodiments where the dispatch table is a single two-dimensional table, numerous 
techniques well known to those of skill in the art of calculating offsets into two-dimensional 
arrays may be utilized. Furthermore, the invention is not limited to tables but may be 
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implemented utilizing any number of data structures including linked lists, hash tables, and 
the like. 

At step 805, the system generates computer code to jump to the location or address 
in the interpreter specified by the field at the offset in the dispatch table. The dispatch table 
is a jump table storing addresses within the computer code of the interpreter itself. During 
interpretation, the epilog computer code performs the advance and dispatch steps for the 
interpreter. However, other embodiments may place the advance step in the prolog and the 
dispatch step in the epilog; therefore, the invention is not limited to the specific 
implementation described herein. 

The above has described preferred embodiments of the present invention. 
Conceptually, one may think that there are five separate interpreters generated: one for each 
of the interpreter states ITOS, LTOS, FTOS. DTOS, and YTOS. However, in practice, 
many of the virtual machine instruction/interpreter state combinations are illegal so five 
separate interpreters are not generated. Furthermore, computer code that executes the virtual 
machine instructions may be shared so an interpreter according to the present invention may 
not be much larger in size than a conventional interpreter. In order to more clearly see how 
computer code that executes the virtual machine instructions may be shared, it may be 
helpful to the reader to describe how computer code for a sample by tecode may be generated 
for the interpreter. 

Exam ple 

As described in reference to Fig. 7, an interpreter may be generated by cycling or 
looping through the possible virtual machine instruction and interpreter state combinations. 
As the interpreter is generated, a section of computer code is generated for each virtual 
machine instruction with a dispatch table being utilized during interpreter execution to hold 
the entry or jump points for different virtual machine instruction and interpreter state 
combinations. Therefore, the generated interpreter may include a dispatch table and a 
sequence of sections of computer code that execute different virtual machine instructions (or 
handle errors). 
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With this example, it will be described how computer code that executes the IADD 
bytecode is generated. Fig. 9 shows a portion of a dispatch table 901 pertaining to the 
IADD bytecode. The structure of dispatch tabic 901 is the same as described in reference to 
Fig. 6. In short, the dispatch table is indexed by virtual machine instructions 903 and 
includes fields 905, 907, 909, 911, and 913, one field for each state of the interpreter. 

The decimal value for the IADD bytecode is 96 as shown in parenthesis. Pointer Aj 
points to a location or address in the interpreter that executes the IADD bytecode if the 
interpreter is in the ITOS state. Similarly, pointers A L , A f , A D , and A v point to a locations 
or addresses in the interpreter that execute the IADD bytecode when the interpreter is in the 
LTOS. FTOS, DTOS, and VTOS states, respectively. 

The pointers in dispatch table 901 point to addresses within the sequences of 
sections of computer code generated for the interpreter. Fig. 10 shows sequences of " 
sections of computer code generated for the interpreter. Each section of computer code 
executes a specific bytecode . Section 1003 includes computer code for execution the IADD 
bytecode. As shown, section 1003 includes two POPL instructions and an ADDL 
instruction. These instructions are assembly language (or native machine instructions) for 
an x86 microprocessor and were generated as follows. 

During interpreter generation, the following sections of assembly language 
instructions may be generated to execute the IADD byte when the interpreter is in the ITOS 
or VTOS states: 

ITOS VT O S 
POPLEDX POPL EAX 

ADDL EAX, EDX POPL EDX 

<DISPATCH/ADYANCE> ADDL EAX, EDX 

<DISPATCH/ADVANCE> 
For simplicity, the computer code that performs the dispatch and advance steps are not 
explicitly shown. As shown, the only difference between the rwo sections of computer 
code is that there is an additional instruction when the interpreter is in the VTOS state. The 
POPL EAX pops a value off the stack of the native machine and places it in register EAX. 
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This instruction was generated as prolog to shift the interpreter from the VTOS state into the 
ITOS state which is the state which is expected for the IADD bytecode (see step 707 of Fig. 
7)- 

The POPL EDX instruction and the ADDL instruction were generated by the 
template function IADD() accessed in the template table (see previous example and step 709 
of Fig. 7). Additionally, the computer code that implements the dispatch and advance steps 
are the epilog computer code (see step 7 1 1 of Fig. 7). As each section of code differs only 
by an initial assembly language instruction, pointers may be utilized to access a single 
section of computer code. 

Accordingly, section 1003 includes computer code to execute the IADD bytecode 
when the interpreter is in either the ITOS or VTOS states. As shown in Fig. 10, pointer A v 
from dispatch table 901 in Fig. 9 points to the first instruction in section 1003 so that the 
initial instruction that puts the interpreter from the VTOS state into the ITOS siate is 
executed. Pointer A! from the dispatch table points to the second instruction in section 1003 
since the interpreter is in the ITOS state. As shown, whether the interpreter is in the VTOS 
or ITOS state, the computer code specified by pointer A, will direct the interpreter to execute " 
IADD bytecodes. 

States LTOS, FTOS and DTOS for the IADD bytecode in dispatch table 901 
represent illegal states for the bytecode. Accordingly, pointers A^ A F and A D pointer to a 
section 1005 of computer code in Fig. 10 that handles the error. The computer code in 
section 1005 typically indicates to the user that the interpreter has been placed in an illegal 
state (see also step 715 of Fig. 7). For simplicity, one section of computer code is shown 
that handles errors; however, more than one section of computer code (or none if error 
checking is not desired) may be utilized. Additionally, the sections of computer code the 
execute virtual machine instructions or handle errors may be arranged in any order. 

Having discussed an example, it may be beneficial to describe a process of 
executing a virtual machine instruction with an interpreter according to one embodiment as 
shown in Fig. 11. The process shown may be utilized to execute virtual machine 
instructions in an interpreter generated as described herein. However, the process may be 
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utilized with interpreters that are generated by other methods so the interpreter generation 
described should not be taken as limiting the implementation of the interpreter. 

At step 1 101, a computer system puis the interpreter in the expected state, where the 
expected state is the interpreter state that is expected before a selected virtual machine 
instruction is executed. In other embodiments, the expected state is the interpreter state that 
is expected before the computer code in the interpreter that executes the selected virtual 
machine instruction is run (e.g., the computer code generated by the template function). 
Step 1101 occurs during interpreter execution and corresponds to the prolog computer code 
generated at step 707 of Fig. 7 during interpreter generation. If the system is in the 
expected state, this step may be omitted. 

The system executes the selected virtual machine instruction at step 1 103. This step 
occurs during interpreter execution and corresponds to the computer code generated by the 
template function at step 709 of Fig. 7 during interpreter generation. 

Once the selected virtual machine instruction has been executed, the system fetches 
the next virtual machine instruction at step 1 i05. Utilizing the next virtual machine 
instruction, the system calculates an offset into the dispatch table at step 1 107. The current 
state of the interpreter after execution of the selected virtual machine instruction is known. 
Therefore, the current state along with the next virtual machine instruction may be utilized to 
calculate an offset into the dispatch table that specifies the location in the interpreter to 
execute the next virtual machine instruction. In a preferred embodiment where the dispatch 
table is implemented as multiple single-dimensional sub-tables, one for each interpreter state, 
the current state specifies the sub table and the offset is calculated utilizing the next virtual 
machine instruction (e.g., virtual machine instruction * a fixed size). 

At step 1109, the system jumps to the address or location in the interpreter stored in 
the field at the offset in the dispatch table. The field may include a pointer to a location in 
the interpreter that executes the next virtual machine instruction. Thus, the jump may cause 
the system to go back to step 1 101 for the next virtual machine instruction. 

Steps 1 105, 1 107 and 1 109 occur during interpreter execution and correspond to the 
computer code generated by the epilog computer code at step 7 1 1 of Fig. 7 during 
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interpreter generation. It should be noted that with the embodiment of the invention shown 
in Fig. 1 l f explicit error checking is not required. Instead, if there is an error, the system 
may jump to computer code to handle the error at step 1 109. Accordingly, error checking 
may be achieved without an impact on performance. 

Conclusion 

While the above is a complete description of preferred embodiments of the 
invention, various alternatives, modifications and equivalents may be used. It should be 
evident that the invention is equally applicable by making appropriate modifications to the 
embodiments described above. For example, the embodiments described have been in 
reference to increasing the performance of the Java virtual machine interpreting bytccodes, 
but the principles of the present invention may be readily applied to other systems and 
languages. Therefore, the above description should not be taken as limiting the scope of the 
invention which is defined by the meets and bounds of the impended claims along with, their 
full scope of equivalents. 
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subtables, one for each interpreter state, the current state specifies the subtable and the 
offset is calculated utilizing the next virtual machine instruction (e.g., virtual machine 
instruction * a fixed size). 

At step 1 109* the system jumps to the address or location in the interpreter stored 
in the field at the offset in the dispatch table. The field may include a pointer to a location 
in the interpreter that executes the next virtual machine instruction. Thus, the jump may 
cause the system to go back to step 1 1 01 for the next virtual machine instruction. 

Steps 1 105, 1 107 and 1 109 occur during interpreter execution and correspond to 
the computer code generated by the epilog computer code at step 71 1 of Fig. 7 during 
interpreter generation. It should be noted that with the embodiment of the invention 
shown in Fig. 1 1, explicit error checking is not required, mstead, if there is an error, the 
system may jump to computer code to handle the error at step 1 109. Accordingly, error 
checking may be achieved without an impact on performance. 

Concision 

While the above is a complete description of preferred embodiments of the 
invention, various alternatives, modifications and equivalents may be used. It should be 
evident that the invention is equally applicable by making appropriate modifications to the 
embodiments described above. For example, the embodiments described have been in 
reference to increasing the performance of the Java virtual machine interpreting 
bytecodes, but the principles of the present invention may be readily applied to other 
systems and languages. Therefore, the above description should not be taken as limiting 
the scope of the invention which is defined by the meets and bounds of the impended 
claims along with their full scope of equivalents. 

4. Brief Description of Drawing 
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Fig. 1 illustrates an example of a computer system that may be utilized to execute the 
software of an embodiment of the invention. 

Fig. 2 shows a system block diagram of the computer system of Fig. 1. 

Fig. 3 shows how a Java source code program is executed. 

Fig. 4A shows a stack; Fig. 4B shows an operand stack of the present invention 
where the value for the top of the operand stack is stored in a register; and Fig. 4C shows 
an operand stack of the present invention where multiple registers and registers for storing 
different data types may store the value for the top of the operand stack. 

Fig. 5 illustrates a template table utilized during interpreter generation to organize 
interpreter states and template functions. 

Fig. 6 illustrates a dispatch table generated during interpreter generation that stores 
pointers to locations within the interpreter utilized to direct interpreter execution flow. 

Fig. 7 shows a process of generating an interpreter that utilizes a state of the 
interpreter to indicate that data type of the value for the top of the operand stack that is store 
in one or more registers. 

Fig. 8 shows a process of generating epilog computer code that executes the 
advance and dispatch steps of the interpreter. 

Fig. 9 shows a portion of a dispatch table of Fig. 6 for executing the bytecode 

IADD. 

Fig. 10 shows sections of computer code for interpreter that execute virtual machine 
instructions and handle errors. 

Fig. 1 1 shows a process of executing a virtual machine instruction with an 
interpreter according to an embodiment of the present invention. 
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Systems and methods for increasing the execution speed of interpreted programs 
which utilize an operand stack are provided. The value for the top of the operand stack is 
stored in one or more registers. A state of the interpreter indicates the data type of the 
value for the top of the operand stack stored in the one or more registers. An interpreter 
may be generated that is both fast and efficient in terms of the memory required for the 
interpreter. 

2. Representat ive Drawing 
F i g . 4 



